To be kept in draft until declared ready to merge by @zooba and @hugovk. I'd like it to make the next patch release but it's not critical to do so, setting 'deferred blocker' just to keep it on the radar.

Let's resolve #150836 first :)

gh-150836 was resolved by GH-151562, which is now included here.

As of 2026-06-26, Tcl/Tk 9.0.4 is current.

I'll start the process of getting main and 3.15 updated to that on the Windows side.

What's the plan with 9.0.4 on Python 3.14?

To be kept in draft until declared ready to merge by @zooba and @hugovk. I'd like it to make the next patch release but it's not critical to do so, setting 'deferred blocker' just to keep it on the radar.

Let's resolve #150836 first :)

We've had it in 3.15 since b2. That issue was a bug in b2, fixed in b3, and b4 has since also come out, and it seems fine.

We already use Tck/Tk 9 in the macOS installer for both 3.14 and 3.15.

So I think we're ready to merge this for 3.14 as well.

Just found this from the b4 logs:

WARNING  Failed to find TCL_LIBRARY

https://dev.azure.com/Python/cpython/_build/results?buildId=172790&view=results

Under:

"Generate layouts" > "Make layouts amd64 / amd64_t / etc" > "Generate full layout"

• https://dev.azure.com/Python/cpython/_build/results?buildId=172790&view=logs&j=0c103224-8ee8-5325-5df0-c5aaffd27de2&t=da04cdca-f3ae-566e-3a4e-e886757e530b
• etc

and:

"Generate layouts" > "Make PyManager layouts amd64 / amd64_t / etc" > "Generate PyManager layout"

• https://dev.azure.com/Python/cpython/_build/results?buildId=172790&view=logs&j=21b48d19-2bb7-580a-8430-2d680b69c0e0&t=c42b2406-2bbc-5122-71b8-53aee01081fb
• etc

Claude summary:

Windows release layouts silently ship without tcl\ under Tcl/Tk 9

The problem

The Windows release pipelines in python/release-tools hardcode
TCL_LIBRARY=<tcltk_lib artifact>\tcl8 before generating package layouts.
CPython's PC/layout script checks that path is a real directory, then copies
its parent (the whole Tcl/Tk lib artifact) into the package as tcl\.

• A Tcl 8.6 artifact contains a tcl8 directory, so this worked.
• A Tcl 9 artifact does not (its lib holds dde1.4, registry1.3, tk9.0,
  nmake, and the embedded-library zips libtcl9.0.4.zip/libtk9.0.4.zip),
  so the check fails, the layout script logs a non-fatal
  WARNING Failed to find TCL_LIBRARY, and silently ships without tcl\.

Evidence

• 3.15 is already affected — it has been on Tcl 9.0.4 since before b1.
  In build Release_v3.15.0b4_20260718.01
  (https://dev.azure.com/Python/cpython/_build/results?buildId=172790),
  stage "Generate layouts", the warning appears in all 15 tcltk-including
  layout jobs:

  • "Make layouts {amd64,arm64,win32}{,_t}" → step "Generate full layout"
  • "Make PyManager layouts {amd64,arm64,win32}{,_t,_test}" → step
    "Generate PyManager layout"

  Example log line ("Make PyManager layouts arm64"):

  2026-07-18T09:28:28.7088959Z WARNING  Failed to find TCL_LIBRARY
  

  The nuget/embeddable/*_embed jobs are unaffected because their layout
  presets don't include tcltk (PC/layout/support/options.py).

• Shipped packages confirm it: python-3.15.0b4-amd64.zip has zero
  tcl/ entries, vs. 1027 in python-3.14.2-amd64.zip (Tcl 8.6, same
  pipeline). Practical impact is modest — tkinter/IDLE still work because
  Tcl 9 embeds its script libraries in the DLLs (Tkinter not installed correctly on Windows 3.15.0b2 #150836) and
  tcl90.dll/tcl9tk90.dll/libtommath.dll are all present in DLLs/ —
  but the optional dde and registry Tcl packages are missing
  (package require dde/registry fails), diverging from the MSI installer,
  which is unaffected (msi-steps.yml passes the artifact root as
  TclTkLibraryDir and tcltk.wixproj harvests **\*).

• 3.14 will hit this too once this PR (the Tcl/Tk 9.0.4
  backport of gh-124111) merges and a release is cut. The tcltk build
  pipeline (tcltk-build.yml) was already updated for Tcl 9 in
  release-tools#378; only the layout stages were missed.

The fix

In windows-release/stage-layout-full.yml, stage-layout-msix.yml, and
stage-layout-pymanager.yml, the "Update TCL_LIBRARY" step now picks
whichever tcl*/tk* directory actually exists in the artifact and fails
the build loudly if none is found, so this can never silently regress again:

# PC\layout copies the *parent* of TCL_LIBRARY into the layout, so it only
# needs to name a directory that exists inside the artifact: tcl8 for
# Tcl 8.6, tk9.0 for Tcl 9 (which embeds its scripts in the DLL).
$tcl = Get-ChildItem "$(Pipeline.Workspace)\$(TclLibrary)" -Directory |
    Where-Object { $_.Name -match '^t(cl|k)\d' } | Select-Object -First 1
if (-not $tcl) {
    Write-Host "##[error]No Tcl/Tk library directory found in $(Pipeline.Workspace)\$(TclLibrary)"
    exit 1
}
Write-Host "##vso[task.setvariable variable=TCL_LIBRARY]$($tcl.FullName)"

Verified selection: tcl8 for an 8.6 artifact, tk9.0 for 9.0 — either
works since only the parent directory is used.

Also removed two per-step env: TCL_LIBRARY: $(TclLibrary) overrides in the
msix stage — a pre-existing bug that clobbered the correct path with the
artifact name (e.g. tcltk_lib_amd64) for the APPX layout steps.

Possible fix at python/release-tools#424.

It doesn't look like we need the tcl directory for v9, and haven't had any bug reports about it, so let's skip it. We can alway add back later if needed.

Let's merge, thanks!